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Abstract 






This oaoer reviews and analyzes the desirable properties or 
a computer network taxonomy from the point of view of its useful- 
ness in a design procedure. A key factor that must be considered 
is that the design environment currently evolving uses function- 
ally high level VLSI-based building blocks to construct various 
network architectures. This paoer begins by reviewing the uses 
ot a taxonomy in a network context, and continues with a review 
of specifications for network requirements. A set of hardware 
interconnection primitives is defined next. A review of the 
Anderson and Jensen taxonomy [\nder751 is then oresented, with a 
discussion of its completeness. The main thrust of this article 
is given in a section on attributes of a design oriented taxon- 
omy. Finally, extensions are oroposed for fault tolerant con- 
siderations and orotocols. 

A computer network is defined to be a hetrogeneous collec- 
tion of computers and the telecommunications subsvstem linking 
them together. Here the properties of the various network archi- 
tectures are of particular interest; the "user'' commuters (or 
processors) are considered as sources and sinks of messages being 
transmitted over the network. Mo distinction as to the geograph- 
ical scope of the network is made because it does not impact the 
taxonomy considerations addtessed here. 



Uses of a Taxonomy 



The derivation of a meaningful taxonomy in any context is 
dependent upon the intended use of the classification scheme. If 
the resulting taxonomy is intended to succinctly convey certain 
attributes of the entities classified then the appropriate nota- 
tion should no doubt be founded upon the most important attri- 
butes of the various entities. Typically the use of taxonomies 
is static in nature, that is, there is no particular emphasis 
upon the dynamics of the classification mechanism itself. 

In some contexts the dynamics of the classification process 
is an important aspect of the taxonomy scheme. For example it 
may be important to quickly classify an entity into the correct 
class. This contrasts to the usual usage of a taxonomy (such as 
in biology) where the taxonomy is used only to infer the attri- 
butes of the entity based uoon its classification. The former is 
a dynamic process involving decision making at several levels; 
the latter is a decoding process based uoon the taxonomy nota- 
tion. 

Thus a taxonomy may be viewed as useful in two complementary 
ways: in one instance, given an unknown entity, classify it 
correctly by making a series of multivalued decisions based upon 
the entity's important (and discoverable) attributes; in the 
other instance, given a set of attributes of interest, discover 
the appropriate class of entities by making a series of 



3 



multivalued decisions based uoon the attributes. Here we use 
"attributes’’ to mean any property of the entity of interest; in 
the network taxonomy context examole attributes are fault toler- 
ance and communications topology. A design orocedure could 
clearly benefit from the latter view of a taxonomy. 

In particular, a correctly defined taxonomy will be useful, 
and even oossibly essential, in a design orocedure for translat- 
ing a set of network requirements into the "best" network confi- 
guration satisfying those requirements. To be useful in this 
manner the designer must know how to measure each of the criteria 
used in the classification scheme, have available an objective 
function which combines the various attributes in a way aopronri- 
ate to the network user's intentions and such that maximizing the 
functional value is tantamount to finding the "best" network. 

In summary, a network taxonomy must be amenable to a 
sequence of multivalued decisions, each of which is based upon a 
measurable criteria aooropriate to the user requirements, such 
that each decision stage successively prunes the solution space 
in an optimal way until a single, best network topology remains. 
Codification of this decision procedure would constitute the 
creation of a very useful and desirable design method. Unfor- 
tunately the knowledge is not presently available to permit a 
definitive design method; much research remains to be accom- 
plished before any universally acceptable design orocedure can be 
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found . 



This paper is primarily concerned with the derivation of a 
taxonomy useful in the manner described. To meet this qoal , 
requirements important to the network user are reviewed, the 
specification of an objective function is reviewed, and then an 
analysis of a particular taxonomy is presented, extensions pro- 
posed, and conclusions drawn. 

M etwork Requirement Sp ecif icat ion 

In this section the specification of network requirements is 
reviewed. An understanding of these requirements is necessary to 
the development of a taxonomy useful to a desiqn method that 
translates those requirements for a given apolication into a best 
network topology. 

kaczmarek and McGregor ( T <acz781 orovide an excellent summary 
on the definition of the networking problem to be solved. They 
state that requirements are of two tyoes: strategical, to oro- 
vide scope and direction to the development of a solution space; 
and tactical, which governs the actual development of a solution. 
These tyoes are categorized as qualitative and quantitative needs 
and desires, respectively. 

Strategical requirements are classed as guidelines (neces- 
sary attributes of an acceptable solution) , data processing fac- 
tors (possible evolutionary oatterns of communication carried) , 
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and issues and oriorities (unresolved factors oossibly impacting 
the strategy). Tactical requirements are the environment (loca- 
tion of user nodes) , data movement requirements (message charac- 
teristics and timing) , performance (level of service provided) , 
and node interface requirements (user to network nrotocol) . 
Judgement as to the necessity or completeness of these require- 
ments is not made here; rather we accept these network require- 
ments as a basis upon which to discuss the role of a network tax- 
onomy scheme in a design method. 

Suppose a user of a potential network has somehow generated 
a set of requirements of the type suggested above. The geograph- 
ical locations of nodes are stated, the properties of the mes- 
sages estimated (arrival rates, message lengths, source- 
destination statistics) , and a user- to-netwo rk nrotocol has been 
established. Can a design method translate these system reouire- 
ments into a best network topology? The answer is ''no'' because a 
measure of what constitutes "best'* has not yet been provided. An 
''objective function - ' is needed that can be used to rank order the 
alternate network configurations by providing a single measure 
acceptable to the network user. The next section discusses the 
nature of an objective function in the network design context. 

Objective Function Sp e cificatio n 

The definition of the particular application tor which a 
network is being designed must be complete enough to indicate the 



6 



relative importance of the strategical and tactical requirements 
in a functional form. This function can be described as an 
"objective function" because it maps values of a set of indepen- 
dent variables (amount of each requirement currently orovided) 
into a single dependent value. This dependent value is to be 
maximized (by definition) , and hence describes the "objective" of 
the optimization process. 

It is often the form of the objective function (and possibly 
of the constraints upon the independent variables) that Provides 
a basis for an algorithm for deriving the optimal values of the 
independent variable; the linear programming problem is an exam- 
ple of this circumstance. It is unknown if the network design 
problem can be formulated in a manner such that an existing algo- 
rithm is applicable. 

Some research on network measures has been accomplished. 
Gonzalez and Jordan [Gon79] have developed a framework for the 
quantitative evaluation of distributed computer systems. They 
define a dimensionless "figure of merit” as a weighted sum of the 
difference between the desired and actual amount of each of a set 
of attributes. They also present an analysis pertaining to the 
form of the weighting and to the effect of adding or deleting 
attributes. In particular they propose an approach that relates 
the figure of merit to a set of "functional primitives" that are 
common to all alternate designs. Examples of primitives are 
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busses, processor and nenory cvcle time, ccrnrnun ication nrotocols, 
and arbitration schemes. This seems to be a oronising approach: 
what remains is to identify network attributes pertaining to the 
user requirements, the derivation orinciples for the attribute 
weights, and the definition of the 3}cO%=9al primitives — hence 
only a framework is presented by Gonzalez and Jordan. 

Several authors have orooosed definitions of the independent 
variables that constitute the set of attributes needed for an 
objective function. Generally they consist of oerformance (a 
throughout measure) , cost and dace modularity, failure effect, 
switching ccmolexity, reconfiguration ootential ( ex tens ib i 1 i tv' 
demise ot security oi integrity, maintainability, and orasent 
value of svstem life cycle cost. These are discussed in detail 
in [Chou74l and [GrubbJSl , the latter being a definition of nine 
performance evaluation criteria recommended by the National 
Bureau of Standards. McGregor and Kacznarek [McG78) describe in 
detail the criteria used in a network model used by the Network 
Analysis Corporation. 

If an objective function includes a. mechanism for manning 
network attributes into functional primitives then the determina- 
tion and definition of these primitives is an important task 
necessary to a network design method. In the next section a set 



of hardware interconnection orimitives is defined. 
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The Hard wate I ntet con nect ion Prim i ti ve Se t 

Because of the nature of digital hardware a basic set of 
hardware interconnection primitives (HIPs) may be defined. From 
this set any functionally representative computer network inter- 
connection subsystem (IBS) can be constructed when the ISS is a 
primary mechanism which influences the operational attributes of 
a network (Carey79] . A later section discusses the ability of a 
oarticular taxonomy to adequately describe ISSs of interest. 

Table 1 summarizes eleven functionally distinguishable HIPs 
needed to construct a functionally representative set of computer 
networks. Part (a) of Table 1 indicates those HIPs that may 
exist in serial or parallel versions. The second grouo ( b) indi- 
cates three other HI D s that can be in anv of several forms and 
group (c) indicates necessary but functionally passive HIPs that 
do not affect the architecture of a computer network. 

More detailed information on these various HIPs is presented 
in a succinct form in Table 2. The exact physical implementation 
of these HIPs is unimportant here; rather we concentrate uoon the 
function of each HIP in the computer network context. Each HIP 
embodies characteristics of and the functionality of hardware 
components used in existing computer networks; for example see 
[ McCoyBO ] . 
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Table 1. Rasic set of HIPs from which the various 
Network architectures can be constructed. 

(a) Tyoe 1 HIPs having both serial and parallel versions 



BIU 


bus interface 


unit 


LIU 


loop inter face 


unit 


U\n 


user adapter , 


n users 


SWn 


switch, any two of n 


L 


link 





( b) Tyne 2 HIPs can be in any of several forms 

communications processor 
bus window 
bus 

memo ry 

( c) Tyoe 3 HIPs that are tunctionally oassive 

BH bus repeater 

BT bus terminator 

number of specific ISSs may be examined within the con- 
text of the >\nderson and lensen [\nder75] classi f ications. fig- 
ure 1 shows a loop network (PPL in the A7 taxonomy) constructed 
from the LIU HI^s described above. Bach IBS is oresented using 
the PMS notation (Bell7il. Figure 1(a) shows a four node POL 
network consisting of LI'Js and links (the Ls) . The unterminated 
lines projecting from the LIUs are ports to user node components 
not shown because they are not logically mart of the network 
Droper. Figure 1(b) illustrates how, in some network configura- 
tions, a UM H I D may be used to interface more than one user pro- 
cessor to the loop. 
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M 
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Table 2. Definition of Hardware Interconnection 'Primi- 
tives. 

Tyne 1 HIPs 



BIU - Dus Interface Unit. Interfaces a ser ial/par allel 
link to a bus; the link side is assumed to conform 
to the bus nrotocol; minimal intelliqence and 
buffering capability; typically interfaces a bus 
with a serial/parallel link; an UAn HI°, a SWn HIP. 
a BW HIP, or a CP HIP; failure does not effect the 
bus . 

LIU - Loop Interface Unit. Interfaces a serial/parallel 
link to a loop type architecture; there is enough 
buffering capability to store several incoming or 
outgoing packets; only a sending LIU can remove a 
packet from the loop; a receiving LIU marks a pass- 
ing packet as ” received’’ , copies it into a buffer, 
and sends the packet on; caoable of synchronizing 
itself with other LIUs; typically interfaces to an 
UAn or a CP HIP; failure disables the entire loop. 

UAn - User Adapter, n users. Interfaces n users to a 
serial/ parallel port; acts as a specialized switch; 
failure typically isolates the n users from the net- 
work. 

SWn - Switch, n ports. Connects any two of n 
serial/parallel ports for the duration of packet 
transmission; has enough intelligence to make a con- 
nection based uoon destination address (based uoon 
routing tables); some buffering capability; act as a 
specialized CP HIP; failure results in all links 
being blocked. 



Figure 2 shows a completely interconnected star configuration 
call DDC in the AJ taxonomy. In Figure 2(a) a four node network 
is shown composed of SW4 HIPs. Again a user adaDter HIP could be 
used to interface mere than one user processor to a node if that 
were desirable. If a five node DDC network is to be constructed 
it could be made from ’’larger” switches, say a SW5 , or it could 
be made from cascading together more than one "smaller" switch, 
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Table 2 continued 
Tyne 2 UIPs 



CP - Communications Processor. General intelligence to 
interface several serial/parallel ports to each 
other; requires a microprocessor; could be soecial- 
ized via orogramming to perform a wide variety of 
functions; failure blocks all communication between 
the ports. 

L - Link. Communications medium; contains no intelli- 
gence; nay contain ''boosters’' to extend its effec- 
tive length; may be serial/parallel; failure breaks 
communication between the end ooints of the link. 

BW - Bus Window. Interfaces two internal busses when 
memory addresses indicate the necessity; in general 
allows the busses to operate indenendently; no 
buffering capability; failure isolates the two 
busses . 

B - Bus. Implements the set of signal lines used by an 
interface system to which a multiplicity of devices 
are connected and over which messages are carried 
[IBS5751; typically a higher bandwidth than a link; 
failure isolates all Bl'Js and stoos all communica- 
tion. 

M - Memory. May be multioort; interfaces to a bus via a 
bus interface unit; failure effect deoends upon the 
Darity/error correction scheme used. 



as shown in part (b) . In the oarticular case one of the ports of 
the SW4s in not used because it is not needed. Figure 3 shows a 
shared memory or DSM network. Users would interface with the 
opposite ends of the links. P iqure 4 shows a shared bus network 
with two bus interface units or Bl'Js; one has a user adapter 
attached. Figure 5 shows a single SW4 UIP used as the hub of a 
central star ICDG network. Again either a larger switch ( ie , a 
SW5) or cascaded switches could be used for the construction of a 



ICDS network of more nodes. 
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Table 2 continued 
Tyne 3 MI R s 

BR - Bus Repeater. Provides a boost in signal strength to 
allow a physical extension of a bus; failure results 
in the isolation of the bus comoonents from each 
o ther . 

BT - Bus Terminator. Prevents reflections from the ends 
of a bus; failure reduces the effective bandwidth; a 
passive 

A loop with central switch is shown in Figure 6. Note the LIU 
HIP is used as in the DOL loop, but here the communications pro- 
cessor HIP (a CP) is employed to effectively produce an "intelli- 
gent LIU". Similarly figure 7 shows a bus with central switch; a 
CP HIP is interfaced to the bus by a BIU. User processes would 
be attached to the other BIUs. 

figure 3 shows an example of a five user node irregular net- 
work ( I DDI ) ccmoosed from SW4s. Mote three of the SW4 are 
underutilized. Figure 9 shows two direct shared bus networks (as 
in Figure 4) interconnected by a bus window HIP. Figure 10 shows 
an I DOR "regular" network made from SW5 HIPs. A variation of 
this using busses is shown in Figure 11; the MICRONCT network 
(Witt731 is an example of an "ID3R" classification which was not 
included in the original AJ classification. 

In this section we have defined a set of hardware intercon- 
nection primitives and exhibited their use in a variety of net- 
work configurations. The usefulness of these HIPs in a design 
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LIU 1 lIU 

I I 

L I, 

I I 

LIU LIU 



A) DDL network with four nodes 



L LIU 






UM 



B) Detail of a single DDL node made to 
adapt up to four user processes by 
means of a UA^ HIP 



Figure 



A DDL network built from the basic set of HIPs. 
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SW4 L SW4 




A) Four node DDC "star" network built 
from completely utilized SW4 HIPs. 




B) Detail of a single node of a five 
node DDC star network. Note how 
the SV/4 HIP on the right is under- 
utilized . 



Figure 2 Examples of DDC "star" networks built 
from the basic HI? set. 



Figure 3 An example of a DSM networx. User 
processes in the computers (Cs) 
interface with the links (Ls). 

\\/y 

. UA4 

I I 

BIU BIU 



Figure 4 A DSB network with one single user 
node and another node supporting up 
to four users . 




Figure 5 A ICDS central star network. 
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Figure 6 An ICDL "loop with central switch" 
networ. . 
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Figure 7 An IC3B "bus with central switch" 
network. 
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Figure 8 An IDDI "irregular network: with six 
user nodes. 
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Figure Q An IDS "bus window" network. 




Figure 10 An IDDR '* regular" network. 
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Figure 11 An IDSR "micronet" network 
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method using the objective tunction ideas of Gonzalez and Jordan 
is unknown; the definition of a useful taxonomy is a prerequisite 
to an answer. In the next section the Anderson and Jensen taxon- 
omy alluded to above is examined from this Doint of view. 

The Anderson and Jensen Taxonomy 

In this section the Anderson and Jensen taxonomy fAnder751 
is reviewed because of its aooarent usefulness as a base for 
classifying network architectures. It may also be extended to 
realize a more comolete taxonomy uoon which to base a network 
design methodology. Its underlying basis is examined and an 
analysis of its strengths and weaknesses concerning its potential 
role in an attribute/functional primitive driven design method is 
made . 

Anderson and Jensen (AJ) view a network as a message passing 
medium with the hardware units forming the interconnection struc- 
ture of a computer network as the basis of a taxonomy. In oar- 
ticular the hardware components of interest are paths and 
switches, as well as user nodes. A oath is the medium over which 
a message packet is carried between orocessing nodes, and a 
switch is the intelligence along an indirect oath between sender 
and receiver. Thus the hardware comoonents are user orocessing 
nodes, paths, and switches. 



A system architecture may then be characterized by the 
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interconnection of these hardware components. AJ state that four 
levels or stages of decision making are adequate to classify the 
different ways in which the hardware components can be intercon- 
nected, and hence a tree structure can be used to represent the 
taxonomy. Figure 12 shows the AJ taxonomy tree. From the top 
level down the decisions concern message packet transfer strategy 
(direct or indirect) , message packet transfer control method 
(none, centralized, or decentralized) , transfer path structure 
(dedicated or shared) , and finally a decision as to the the final 
network topology. 

The usefulness of the AJ taxonomy in a network design pro- 
cedure depends upon the ability to relate the four levels of 
decision to the original design requirements. Exactly how the 
design requirements translate directly or easily into a decision 
on, say, message Dacket transfer strategy is not immediately 
clear. It may be that other decisions can be made directly (and 
early on) from user requirements that have the identical effect 
of pruning the tooological solution soace. 

Several computer network toooloqies do not fit smoothly into 
the AJ taxonomy. Various hybrids of the basic ten topologies can 
exist. These may be in the form of hierarchical networks such as 
RHEA [Pow7Rl , or just coincidental networks interconnected by a 
''gateway” [Dav79]. As mentioned earlier the MICROMST network 
forms a new leaf in the AJ taxonomy tree which may be termed an 
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Figure 12 The Anderson and Jensen network taxonomy. 
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IDSR tyoe network. Component redundancies tor fault tolerance 
are not expressible in the AJ taxonomy, nor are any aspects of a 
network nr o toco 1. 

In summary, the AJ taxonomy may be incomplete and even inap- 
propriate for the design procedure environment but seems to pro- 
vide the best conceptual structure at this time. The next sec- 
tion addresses those attributes necessary in a taxonomy from the 
design procedure viewpoint. 

The Completen e ss of the AJ Taxo n om y 

In this section we examine the completeness of the AJ taxon- 
omy with regard to the fundamentally unique network topologies. 
Recall that AJ define a "system architecture" level beneath three 
other layers of decision concerning transfer strategy, transfer 
control method, and transfer control structure. At the third 
level there exists three sets of dedicated oaths an" 5 shared oath 
oairs, the maximum provided by the decision alternatives allowed. 
From these six nossibil ities AJ define ten system architectures. 
It may be that other possibilities exist as was indicated by the 
Micronet system. 

The first of the six transfer path structure possibilities 
is the DOx grouping that is subdivided into the DDL and DOC clas- 
sifications. Clearly the DDL is the minimal way of connecting a 
given number of nodes in the DOx context and the DDC is the maxi- 
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mal way of ccnnsctinq a set of nodes. It appears that adding more 
paths to the DDL network or removing sons oaths from the me net- 
work adds nothing significant in the way of system architecture. 
Such intermediate network types could be aooropr iately classified 
as an imi ’’irregular", hence this group is complete. 

The second grouping is the OSx set, resulting in the OSM and 
OSS architectures. The distinguishing point here is the inclu- 
sion of memory as the path or not; note the bus behaves only as a 
temporary memory device. Here again the two subclasses are 
exhaustive, and so no new unique architecture can exist. 

The ICOx grouping is next; it results in the ISOS 'star” and 
the ICDL "loop with central switch" subtypes. By definition mes- 
sages are sent to the switch and then retransmitted to their 
final destination. Within the ICO systems it seems that only the 
two possibilities can exist, and so this grouping is complete. 

Only one architecture for the ICS grouping is defined by A7. 
This "bus with central switch" architecture seems unique in that 
all the shared path types rely on a bus, and a centralized rout- 
ing switch can be included in only one way; hence this class is 
complete. The definition of a switch in this classi f ication 
seems too restrictive. A centralized bus arbitration scheme 
might be allowed in the ICS group, even though the message might 
be sent directly to the receiving node without retransmission. 
This appears to follow from A J ' s definition of a switch as "the 
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intervening intelligence between sender and receiver'. Thus a 
oolling scheme, such as used in SHIMPADs [Kuhns791 , might be per- 
mitted in the ICS classification. 

The fifth grouo, IDOx , is subdivided into "regular" and 
"irregular", clearly an exhaustive set. Thus this group seems 
complete . 

The last grouo is IDSx , consisting of the one classification 
I OS "bus window". In general this permits an irregular structure 
of basses. Since at least one "tegular" network of the IDS tyoe 
is described in the literature a second subclassification within 
this group should be defined, namely an "IOSR" type. The network 
described by this class is ''’ittie's M ICRONTT ('*’itt781. To our 
knowledge this is the only non-hybrid network found in the 
literature requiring another system architecture within the AJ 
f raraewo rk . 

In summary, an analysis of the AJ taxonomy in terms of 
experimental networks indicates only one new system architecture 
exists, given the manner used to define the subclassifications; 
otherwise each grouo is divided into exhaustive classes, based 
upon some criterion such as interconnection, memory capability, a 
switch, regularity, or interconnection device type. We conclude 
that as far as basic classifications are concerned the AJ taxon- 
omy is adequate, given the premise uoon which it is based. 
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Attr ibuces of a Design Orie n ted Tax on omy 

In this section a basis for a network taxonomy amenable to 
an attr ibute/f unc tional primitive driven design method is 
presented. The primary emphasis is placed upon the topological 
selection criteria; it may be that other considerations would 
influence the development of a taxonomy in other ways. 

A useful taxonomy in a design environment should address the 
strategical aspects of a network tooolcgv critical to the network 
user. Examples of these aspects are the ability of a network to 
transmit the current and future message packet load; that it be 
ma inta inable and extensible, that it be fault tolerant to the 
degree desired; that it be place and cost modular with resoect to 
the addition of future node sites; and that it be least expensive 
in terms of present value of life cycle cost. The main problem 
is to identify all the criteria that relate to topolonical deci- 
sions, relate them to user requirements, determine their relative 
importance to each other, and express the sequence of decisions 
in such a manner that the topological solution space is quickly 
pruned . 

One approach to deriving such a taxonomy is to configure the 
possible computer networks given a set of 'lIPs, identify the 
resultant network attributes in relation to user requirements, 
and then to derive an appropriate sequence of decisions. This 
might be called a "bottom up" approach. A "top down" approach 
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might be to identify the relationships between user requirements 
and decisions affecting network tonology, making sure the deci- 
sions are answerable in terms of user requirements. The latter 
approach is more applicable to a design procedure, and so is pur- 
sued here. 

The question is what user requirements relate to the highest 
level of network topological decision making. Clearly geographi- 
cal considerations are one component in the highest level 
category. For example a network covering a large geographical 
area is most likely to be of an "irregular" nature just to keep 
interconnection costs reasonably low. However this need not be 
necessarily so: given appropriate traffic characteristics a radio 
medium based network (such as ALOHA [Abram701, or a satellite to 
user network) may be the least expensive in interconnection 
costs. Still, certain tocologies might be excluded, such as loop 
or bus based networks, so geographical dispersement may be useful 
at a high level in a design procedure. If that is the case should 
the design decision be stated in terms of "message transfer stra- 
tegy" (as it is in the AJ taxonomy) or some other statement 
closer to the requirements of the design problem? 

Performance measures have the same type of problems. Given 
a performance measure (for example, messages per second) how does 
a designer infer a topological conclusion? The problem here is 
that any topology could theoretically be made to carry any mes- 
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sage load, liven appropriate technology. It may be that the 
functional primitives (HIPs in particular) could provide guidance 
in this area. The cost per bandwidth unit will be a step func- 
tion in a building block design environment, hence matching per- 
formance to HIP may infer decisions about applicable ISSs and 
therefore network topologies. 

The next section examines the possibility of extending the 
basic AJ taxonomy to include redundant HIPs for fault tolerance 
purposes . 

Taxonom y Ext ension s fo r g a u 1 1 ^olera nee Con s id e rat ion s 

An additional important consideration is the extension of 
the basic AJ taxonomy to include a notation to express the fault 
tolerant behavior resulting from the inclusion of HI D redundan- 
cies. This tooic is specifically chosen because of its impor- 
tance to network users and designers. As the AJ taxonomy now 
stands only the basic properties of a particular classi t ication 
are described; additional HIPs that might be added tor a soecitic 
purpose, such as fault tolerant reasons, have no mechanism Per- 
mitting their description. 

An example DSB architecture with a second, redundant bus is 
shown in Figure 13. Here the bus interface units (BIUs) are 
modified from the earlier definition such that two busses may be 
interfaced; note however, that they remain lonicallv identical 
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functional Primitives. Each BIN must now contain the ability to 
compare the behavior of both busses and to determine which 
behavior is most likely to be correct. The point is that the 
fault tolerant IBS shown in Figure 13 remains a DEB architecture 
because of its overall behavioral attributes. 

Equivalent situations can be easily formulated for the other 
classes of networks. DDL loop networks could be in '’parallel” if 
suitable modifications were made to the LIUs. ^ny of the "regu- 
lar” topologies could be modified in a similar manner. Some of 
the basic architectures imbed an equivalent level of fault toler- 
ance without the need for additional, redundant components. For 
example, the MiCRONST architecture mentioned earlier (a "regular" 
network of DEB architectures) already has the fault tolerant 
capabilities of the duplicate bus DEB described above. Hence the 
MIC RONE T ' IDSR" architecture has inherent fault tolerance to some 
degree, and so does not necessarily require an extension to the 
taxonomy notation to express this fact. Thus the explicit refer- 
ence to a duplicated HI D component does not seem to be a good way 
to exoress a level of fault tolerant capability. 

Mother approach to expressing a fault tolerant capability 
might be to determine the types of effect a single component HIP 
failure may cause. This may be called a "failure effect" way of 
describing fault tolerance, in contrast to a component oriented 
notation. For example, in the duplicated bus DEB configuration 
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we could state that a failure of one of the two busses would 
cause no loss of communication between user nodes. Still, the 
failure of another HIP, say the BIU in this case, might isolate 
the user Drocesses attached to it but not affect the communica- 
tion between the remaining user processes. Thus at least two 
major failure effect modes, loss of node and loss of network, 
must be resolved. This implies that the particular type of com- 
ponent HIP that tails must be taken into consideration in a use- 
ful notation. 

Given the situation described above it seems appropriate to 
define classes of fault tolerance suitable to describe the effect 
of its failure. Thus positional notation could be used to indi- 
cate the type of Hit 5 failure, and encodings in each position 
could be defined to indicate its failure effect. A two component 
encoding is therefore proposed, both of which indicate a tailure 
effect of a class of HIPs. The first component of the pair 
relates to the failure of an interface MI n , and the second com- 
ponent of the pa i r to the failure of a communication path HIP (a 
link or switch) . Encodings for the effect must be descriptive, 
succinct, and easily remembered; we suggest "T'' for tolerant, "L" 
for localized, and "V" for vulnerable. Table 3 indicates the 
definition of these encoding in more detail. 



Certainly more detail could be included into the notation but it 
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Table 3. Effect Encodings 



Encod ing 



Failure Effect 



T 



Tolerant fault effect behavior. 
Failure means no loss of network 
capabil ity. 



L 



Localized fault effect behavior. 
Failure means only locally attached 
user processes are isolated from 
the remaining processes. 



V 



Vulnerable fault effect behavior. 
Failure means the entire network 
becomes inoperative. 



would be of little additional value to a reader interested in the 
particular fault tolerant behavior of the network; other nota- 
tional schemes, such as a graphical representation of the net- 
work, could provide implementation details to a reader, if addi- 
tional detail were needed. 

The notation proposed is the use of the PMS notation of Bell 
and Newell [Bell711 in which attributes of a system are enclosed 
in square brackets. In this context the first entry is the *L7 
classification code, the second entry codes the effect of an 
interface HIP failure and the third codes the affect of a nath 
'UP failure: 

NETWOl E : = [<class ccde> ; <ta ilur e code>; <fa ilure code>l 
where each <ta ilure code> is a "T"' , ”L', or a ''V". 



The worth of the proposed extension to the basic *LJ classif- 
ication scheme can best be demonstrated by some examoles. 



Consider the duolicated bus bSB architecture of Figure 13; in the 
oroDosed notation it could be described as singly DCS (if its 
fault tolerant behavior was not inportant) or as [bSB;L;T]. The 
"L” refers to the local effect of a BIU failure and the 
reters to the tolerant behavior in the face of a single bus 
failure. An ordinary D5B architecture (without a duolicated bus) 
could be classified as a (DS3;L;Vl. Similarly there could exist 
a (DDL;L;T]. Figure 14 shows an obvious configuration for a 
fObL;L;T] and Figure 15 shows another equivalent version. The 
notation proposed here does not distinguish between the two ver- 
sions (because their fault tolerant behavior is identical) , hence 
implementation details are not exolicitly indicated. 

MICRONCT could be classified as an IbSR or as an (IOSR;L;Tl 
without regard to the presence of MIR redundancies. Similarly a 
DOC "complete'' architecture could be classified as a (bbC;L;Tl 
without HIP redundancies. The situation ct the IbbI "irregular" 
networks in not sc clear. For user nodes connected in a minimum 
scanning tree manner (fewest number of links possible) a path 
failure could isolate (in general) more than one node's user 
processes from the others and hence would be an (IObI;L;Ll. If 
more paths existed within the irregular network it could be of 
the class ( IDOI ;L jT] . Thus in the IObl case redundant HIPs have 
a variable effect on fault tolerance depending upon the number 



and Placement of the redundancies. 



- 32 - 



We have shown how oath HIP components may be configured such 
that a network may require a T, L, or V encoding. In contrast 
all the examples shown have had the first "interface failure 
effect" code a "L" for a localized effect. In general the code 
can become a "T" only when an interface unit is duplicated and 
the same user processes connected to both interface components. 
The resulting situation is that two nodes now exist where only 
one existed before, and so a larger network results. Hence the 
fault tolerance capability is "outside" the network oroper and 
need not be exnlicitly shown. The interface coding can become a 
"V" only when a unit (say a LIU) failure blocks all communication 
in the network. 

In summary the notation proposed here is useful in describ- 
ing the fault tolerant effect of interface unit failures and path 
failures. Three levels of effect are provided for each type of 
failure. Mote detail is considered to be of little practical use 
and would result in a more complicated encoding scheme than its 
worth. The value of the notation scheme proposed has been demon- 
strated by several examples. 

Taxonomy Hxtens ions for Pro t ocol s 

A useful taxonomy classification scheme should have provi- 
sions for the inclusion of the description of an appropriate 
level of protocol because it conveys the type of user terminal 
equipment that could be attached and something about the 
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per to nance character ist ics of the network. This section reviews 
the problems associated with the development of such a notation 
and make a recommendation fot a oarticular scheme. 

A communications Protocol is defined as those conventions 
necessary for the orooer transmission of messages over a netwotk. 
Typically, several layers of protocol are defined cor respond inq 
to the various functional needs involved. *Vn advantage of con- 
siderin'! layers of Protocols is that each functional layer can be 
made essentially independent of the other lavers, such that 
changes in any particular layer need not affect the others. 
Several definitions of the various layers exist in the literature 
and are germane here. For purposes of discussion the Interna- 
tional Standards Organization (ISO) model of protocol lavers is 
shown in Table 4 [ISO]. 



Table 4. ISO Protocol Level Model. 



Level number 



Function 



7 

6 

5 



Process control. 
°resentation control 
Session control. 



(transport mechanism) 



4 

3 

2 

1 



Transport end-to-end control. 
Network control. 

Link control. 

Physical control. 



Of importance here is what constitutes the appropriate level for 
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inclusion in a useful taxonomy scheme. The two basic choices are 
at the "host-to-host" level or the Dhys ical/1 ink level. 

Consider the "host-to-host” level; this is the level that is 
'seen” by the network user. In the ISO model shown in Table 4 
the user sees a combination of levels 4 and 5, which are con- 
cerned with both sides of the transport medium barrier. Walden 
and McKenzie [Wald791 point out this fact as an indication of the 
possible inappropriateness of the ISO model. Some other host- 
to-host protocols have been defined: examples are the Department 
of Defense (the Arpanet TCP protocol and the ^utodin II proto- 
col) , the Consultative Committee for International Telegraphy and 
Telephony (CCITT) X.25 (includes a physical link level X.21, a 
logical link that is a subset of the HDLC protocol, and a packet 
level interface protocol) , as well as various computer vendors 
such as ISM, DSC, Prime, Burroughs, etc. Much international 
effort at standard ization is underway to define a true interna- 
tional standard but events (like a de facto standard) could over- 
come them and render them moot. 

a^n alternate approach may be to concentrate upon the physi- 
cal control level of protocols only, leaving the higher level of 
interfacing unstated. The problem with this is that even this 
level is not resolved as to standardization. Still the issues 
are not as volatile and at least one acceptable protocol is 
widely used even now. This is the PS-232 protocol for which 
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many terminal units are manufactured. Example cf other orotocols 
are X.24, X.25 (US-423), X.27 (PS-422), an* CIS 4093; see 
( c ’olts791 tor a discussion of these orotocols. 

Another standar d i za t ion effort is currently underway by the 
ICES (see ‘^arch 27,1930 issue of Electronics, o. 40). This 
effort is directed specifically to local comouter networks; how- 
ever, they should have siqnificant ramifications to computer net- 
works in qeneral. 

At this time it seems aopropriate to define a notational 
scheme for the host-to-host level in soite of the fluid state of 
affairs at this level. We make this decision solely uoon its 
usefulness to the potential network user and to the network 
designer. This follows Darticularly from the fact that a proto- 
col at this level usually implies a physical level protocol as 
well, although it need not do so. 

Considering orotocols at this level as part of a taxonomy 
classification scheme represents some risk because of the stan- 
dardization effort versus the manufactures rush to market a par- 
ticular vendor unique system. Even so we make a recommendation 
in this resnect. The particular nature of the recommendation 
follows the format of the optional fault tolerant notation 
described in the preceding section. As before the encodings 
should be succinct and meaningful. Table 5 lists some of the 
protocols currently in use; other most likely exist. At this 
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tine no attempt is made to encode each protocol tyoe. Instead, 
until several de facto or true standards come into prominence we 
sugqest that the full names shown in Table 5 be used. The list of 
networks is adapted from [Pree791 . 



^or example a particular network could be classified as a 
[DSS ; ETHERNET] . A fault tolerance field could also be appended: 
[DSS ; L ; T ; ETHERNET] . 

In summary we recommend that an optional appendage indicat- 
inq the type of host-to-host protocol be made a part of a taxon- 
omy scheme. Its presence would convey important information to 
the reader, and would be useful to a future design method. We 
choose to use the commonly accented notations for the various 



Table 5. Protocol Tyoes 



Cm* 

LCS 

ICS 

SPIDER 

^IRERNST 

M IN INST 

DATARIMG 

RIT NETWORK 

DON 

C . mmp 

AN/NSQ-67 

DCS 

DLCN 

DDLCM 

SATNST 

HYPERCHANNEL 

LASL 

LASOLINX 
X. 25 



EPIC-DPS 

TECHNSC 

SHINPADS 

MISS 

IRCM 

DNC 

MITRENET 
IS’Jnet 
KHIPNET 
°LURIS'JS 
ARGDNNE 
CYS ERNST 
ETHERNET 
NS S 

PRIMENET 

RIG 

CERN 

DCTOP'JT 
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networks currently used until that tine true internationally 
recognized protocols at this level are 

S unma r y 

'»/e have reviewed the attributes of a network taxonomy for a 
design procedure context. Among the conclusions drawn is a 
determination that the Anderson and Jensen taxonomy is sufficient 
for characterizing the high level structures of networks and 
appears to be useful as a base uoon which to define extensions 
that encompass implementation considerations , fault tolerant 
attributes, an-' 1 communication protocols. Particular extensions 
are proposed that seem advantageous in the high level functional 
primitive building block design environment. The next area that 
must be studied is the objective function area before a good 
design method for networks can be devised. To some extent work 
on nrotoccl descriptions is dependent uoon international and 
national standardization efforts, in addition to research into 
protocols themselves. In summary we believe the taxonomy exten- 
sions proposed here should orove to be of use in a future design 
procedure for the computer network context. 
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